Ethereum signatures are scoped by signing domain to ensure that when
data of different types happens to encode as same byte representation
that the resulting hash being signed does not collide across domains.
This is typically done by prefixing the data with the domain constant
before signing it. The following signing domain constants are defined:

- 0x00: Unused for signing, but represents Homestead tx on JSON-RPC
- 0x01: EIP-2930 transaction
- 0x02: EIP-1559 transaction
- 0x03: EIP-4844 transaction
- 0x04: EIP-7702 transaction
- 0x05: EIP-7702 authorization
- 0x19: EIP-191 signed data
- 0x80-0xfe: Homestead transaction
- 0xff: Reserved by EIP-2718

EIP-2718 aliases transaction types to a subset of the signing domains:

- 0x00 represents a tx but is not used for signing.
- 0x01-0x04 represent a tx and are used for signing.
- 0x05 and 0x19 do not represent a tx but are used for signing.
- 0x80-0xfe represent as 0x00 on JSON-RPC but are used for signing.
- 0xff is reserved and neither represents a tx nor is used for signing.

To improve simplicity as future transaction types are introduced, it may
be desirable to group related constants together.

For that reason, it is proposed to change the signing domain used for
EIP-7702 authorization from `0x05` to `0x1a`. Rationale:

- This allows a future transaction type to use type 0x05 sequentially.
- If transaction types ever enumerate through 0x18, there is already
  the problem of 0x19 being in use. Therefore, assigning 0x1a to be used
  for EIP-7702 authorizations does not introduce additional problems
  beyond what already will have to be dealt with.
- If a new signature algorithm is introduced, one may still do so by
  setting the upper bits in the signing domain, e.g., 0x40 or 0x20 are
  still left untouched if 0x1a is assigned. This is an advantage over,
  e.g., assigning 0x20 to EIP-7702 authorization signatures.